Displays the current frame number, timestamp, and frame type at the current position. Frame types are as follows:
</p>
<ul>
<li><tt>[K]</tt>: A key frame. (AVI)</li>
<li><tt>[ ]</tt>: A delta frame — stored as a difference from the previous frame. (AVI)</li>
<li><tt>[D]</tt>: A drop or null frame, which repeats the previous frame. These are most often found in capture files. (AVI)</li>
<li><tt>[I]</tt>: An I-frame; similar to a key frame. (MPEG-1)</li>
<li><tt>[P]</tt>: A P-frame, or <i>forward predicted</i> frame. These are stored as a difference from an earlier frame. (MPEG-1)</li>
<li><tt>[B]</tt>: A B-frame, or <i>bidirectionally predicted</i> frame. These are stored as a difference from both an earlier frame and a future frame. (MPEG-1)</li>
<li><tt>[M]</tt>: A masked frame. These are frames that have been tagged in VirtualDub's timeline as not to be processed; instead, the previous frame should be
used. This is most often used to bypass errors in the source. The end frame will also show up as one of these.</li>
</ul>
<p>
The format of the timestamp display can be customized in Preferences.
</p>
</dd>
</dl>
</lina:create>
<lina:create file="p-edit.html" title="Processing: Editing the source video">
<p>
Although VirtualDub is not a full non-linear editing (NLE) application, it does have some limited
functionality for editing source video. Unwanted portions of video can thus be trimmed off from
a video before it is processed, saving disk space and time.
</p>
<h2>Selecting and editing portions of the timeline</h2>
<p>
Use the <em>Edit > Set selection start</em> and <em>Edit > Set selection end</em> commands to select
a portion of video. This can also be done through the Home and End keys on the keyboard, or through
the mark-in and mark-out buttons below the position slider. The current selection is then indicated by
a sky-blue area on the position slider.
</p>
<p>
Once a portion of video has been selected, the <em>Delete</em> command (keyboard shortcut: Delete key) can
be used to remove that video from the timeline. The <em>Cut</em>, <em>Copy</em>, and <em>Paste</em> commands
can also be used to reorder video (they cannot be used to splice or combine video files together, however).
The <em>Undo/Redo</em> commands can be used to reverse mistakes, and the <em>Reset timeline</em> command
undoes all edits entirely, restoring the timeline to the entirety of the source video.
</p>
<p>
Editing the timeline only creates an edit list within VirtualDub for later use; it never modifies
the source file in any way. In particular, deleting a section of the timeline does not delete anything
from the source file, and the edited result must be saved to a new file. Editing a video file thus requires
disk space to hold both the original and the edited clip.
</p>
<p>
As a shortcut, the selection mark-in/mark-out commands also modify the range selection that is exposed via
the <em>Video > Select range...</em> menu command. Thus, selecting a portion of video prior to a save
command causes only that selection to be rendered to disk. If this is undesired, clear the selection using
the <em>Edit > Clear selection (Ctrl+D)</em> command.
</p>
<h2>Caveats when editing</h2>
<p>
VirtualDub does not have support for transitions, so any edits will be abrupt unless the edit points are
located at places in the source video that hide the seam. Silent fades to black are a good place to
remove selections of video.
</p>
<p>
Editing can be performed in any video or audio mode, including Direct mode, which causes the render-to-disk
to be extremely fast and without quality loss in most cases. However, there are serious limitations with
editing in this mode that restrict where edits can be performed; also, advanced audio and video compression
can impede VirtualDub's ability to edit cleanly. For more information, see <a href="p-direct.html">Direct mode</a>.
</p>
<h2>Masking frames</h2>
<p>
A single frame or section of frames can be <i>masked</i>; this prevents the imagery from those frames
from being used and instead forces reuse of the image of the last unmasked frame. In Direct mode,
the masked frame data is deleted entirely and empty padding frames are written instead. However, in
either case the audio is untouched, so the video simply appears to freeze for the duration of the
masked range. This can be used either to remove single-frame glitches or to remove compressed frames
that are damaged.
</p>
<p>
Note that similar restrictions apply to masked frames as to deleted frames with regard to masking frames
that are not key frames, and VirtualDub will similarly fix masked ranges that cannot be supported
in Direct mode.
</p>
</lina:create>
<lina:create file="p-render.html" title="Processing: Rendering and saving the processed output">
<p>
Once the source video has been edited as necessary and appropriate processing parameters set, the
video can be <em>rendered</em> to generate the final result. This can either be previewed live or saved
to a file on disk.
</p>
<h2>Previewing the edited result</h2>
<p>
The <em>File > Preview output from start...</em> command begins rendering the timeline to the video
display so that it can be previewed. Most video and audio processing operations are active in this mode,
with the notable exception of audio and video compression, which are disabled. The result that is seen
in the output display pane and heard from the system speakers is thus representative of the output of
the video and audio filter systems, but may be of higher quality than what would be stored in compressed
form.
</p>
<p>
Rendering filtered audio and video in real-time consumes a lot of CPU power and in many cases VirtualDub
will have difficulty attaining full frame rate given a complex filter chain. When this occurs, the audio
may lose sync and begin to stutter as the video frame rate drops below real-time, since all video frames
are still displayed. The <em>Option > Drop video frames when behind</em> option can help here by allowing
VirtualDub to process only a portion of the video frames in order to maintain real-time performance.
This only affects preview and does not remove frames during any save-to-disk operation.
Note that this may not be sufficient in extreme cases where the audio chain or the hard disk is unable
to attain real-time either.
</p>
<p>
The <em>Sync to audio</em> option also affects preview by changing the way that VirtualDub synchronizes
audio and video playback; it should normally be left on, but if there are problems with audio timing
that prevent synchronized playback from occurring, disabling this option may allow preview to proceed.
Like the option to drop frames, this option too only pertains to previewing and does not affect renders
to disk.
</p>
<h2>Saving the processed result to disk</h2>
<p>
<em>File > Save AVI...</em> starts a render process to disk. A new AVI file is then generated containing
the processed video and audio.
</p>
<p>
VirtualDub is normally able to write AVI files larger than 2GB using a extension to the AVI file format
called the <em>OpenDML hierarchical index</em>. This is done in such a way that older applications that
do not understand the hierarchical index can still open the first 2GB of the file. However, occasionally
an application cannot open such AVI files at all. The <em>File > Save old format AVI</em> command
disables VirtualDub's use of that extension so that only an original-format AVI is written. Note that
this format does not support AVI files larger than 2GB, so care must be taken to appropriately trim or
compress the video to fit below this threshold.
</p>
<p>
If only the audio is desired, the <em>File > Save WAV...</em> menu option produces an audio file on
disk using the WAV format. All audio options are active, except for the interleaving interval, which
does not apply since no video is being written. Video is not processed in this mode. Note that audio
compression <i>is</i> active since WAV files can either be compressed or uncompressed, so be sure to
disable audio compression if an uncompressed WAV file is desired.
</p>
<p>
Although VirtualDub can read MPEG-1 files, it is not currently able to write them, even in Direct mode.
</p>
<h2>Analysis passes</h2>
<p>
Some video filters and video codecs may require <i>analysis passes</i> in order to effectively filter or
compress video. In the analysis passes, the video is scanned to determine difficult areas of motion or
other features; knowledge of the <i>entire</i> video can then be used to optimize the final output.
This is known as <em>multi-pass</em> processing.
</p>
<p>
For various reasons, VirtualDub does not know that a multi-pass operation is required by a video filter
or codec and cannot automate the process. However, the <em>File > Run video analysis pass</em>
assists in running analysis passes by running the video pipeline without writing a dummy file to disk.
The audio pipeline is disabled as well for additional speed.
</p>
</lina:create>
<lina:create file="p-pipeline.html" title="Processing: The pipeline">
<style>
table.pipeline {
}
table.pipeline th {
background: #8ae;
}
table.pipeline td {
background: #aea;
}
</style>
<p>
VirtualDub's processing of audio and video during a render-to-disk operation is split into several pipeline stages.
Some of these stages are enabled or disabled depending on the current audio/video mode selected.
</p>
<h2>Video pipeline</h2>
<p>
The video pipeline can be run in one of four different modes:
</p>
<ul>
<li>
<p>
<em>Direct stream copy</em>: In this mode, video frames are copied directly from input to output. No
recompression takes place, and thus no quality loss can occur. This is the fastest possible mode for
editing video in VirtualDub.
</p>
<p>
Because the video is not recompressed, video compression imposes restrictions on how the video can
be edited.
</p>
</li>
<li>
<p>
<em>Fast recompress</em>: Video is decompressed and then recompressed using the desired output codec.
VirtualDub automatically chooses a intermediate video format to use between the codecs for quality
and speed.
</p>
<p>
An output video codec must be chosen in this mode.
</p>
</li>
<li>
<p>
<em>Slow recompress</em>: Video is decompressed and then recompressed using the desired output codec.
This is similar to Fast Recompress except that the input and output formats can be chosen
in the <a href="d-videocolordepth.html">Video color depth</a> dialog, and the two can be different,
requiring a conversion in between.
</p>
<p>
If no output video codec is chosen, the video is written to disk uncompressed in the output format.
</p>
</li>
<li>
<p>
<em>Full processing mode</em>: All pipeline stages and features are enabled.
</p>
</li>
</ul>
<p>
Here's what the video pipeline looks like:
</p>
<blockquote>
<table class="pipeline">
<tr>
<th>Direct</th>
<th>Recompress</th>
<th>Full</th>
</tr>
<tr>
<td>Frame sequencing</td>
</tr>
<tr>
<td>Read frame</td>
</tr>
<tr>
<td rowspan="6"></td>
<td>Decompress frame</td>
</tr>
<tr>
<td rowspan="3"></td>
<td>Inverse telecine</td>
</tr>
<tr>
<td>Convert to 32-bit RGB</td>
</tr>
<tr>
<td>Run video filters</td>
</tr>
<tr>
<td>Convert to target format</td>
</tr>
<tr>
<td>Compress frame</td>
</tr>
<tr>
<td>Write video</td>
</tr>
</table>
</blockquote>
<p>
Here's what the various stages do:
</p>
<dl>
<dt>Frame sequencing</dt>
<dd>
<p>
Video frames are selected from sources and ordered. This is where any edits done to the timeline take place,
along with the frame rate options, including rate adjustment, conversion, and decimation.
</p>
<p>
If Direct mode is selected, there are some restrictions as to how frames can be inserted or dropped. Any edits
to the timeline that violate these restrictions are adjusted here to comply.
</p>
</dd>
<dt>Read frame</dt>
<dd>
<p>
Video frames are read from disk.
</p>
</dd>
<dt>Decompress frame</dt>
<dd>
<p>
Compressed video frames are run through a video codec to produce uncompressed video frames. The format is
selected in the <a href="d-videocolordepth.html">Video color depth</a> dialog.
</p>
<p>
In Fast Recompress mode, the format is automatically selected based on compatibility between the input and
output video codecs.
</p>
<p>
By default, any empty ("dropped") frames in the input are simply duplicated here. This behavior can be
changed through the <em>Video > Preserve empty frames</em> option, which causes each empty frame to
be copied straight to the output, regardless of the video filter chain or output codec. This can be useful
if the video stream has been upsampled to a higher frame rate using empty frames.
</p>
</dd>
<dt>Inverse telecine</dt>
<dd>
<p>
If inverse telecine (3:2 pulldown removal) is enabled in <a href="d-videoframerate.html">Video frame rate
control</a>, fields are reordered and the video stream frame rate is reduced by 25% at this point.
</p>
</dd>
<dt>Convert to 32-bit RGB</dt>
<dd>
<p>
Video filters in VirtualDub currently only run in 32-bit RGB, so the video frames are converted to 32-bit
RGB at this point.
</p>
<lina:note>
In previous versions of VirtualDub, enabling full processing mode would always force a conversion to 32-bit
RGB. This is no longer the case — if no video filters are used, this conversion step is omitted
and the video is directly converted to the output format as in Slow Recompress mode.
</lina:note>
</dd>
<dt>Run video filters</dt>
<dd>
<p>All <a href="d-videofilters.html">video filters</a> are run at this point.</p>
</dd>
<dt>Convert to output format</dt>
<dd>
<p>
The video frames are converted from their current format to the output format specified
in the <a href="d-videocolordepth.html">Video color depth</a> dialog. If the formats are the same,
no conversion takes place.
</p>
<p>
Conversions between YCbCr formats are done directly in YCbCr space without an RGB intermediate step.
Chroma is subsampled or supersampled as necessary using bilinear filtering.
</p>
</dd>
<dt>Compress frame</dt>
<dd>
<p>
If a <a href="d-videocompression.html">video compression codec is selected</a>, it is now used to
compress the video frame.
</p>
</dd>
<dt>Write video</dt>
<dd>
<p>
The video frame is now written to disk.
</p>
</dd>
</dl>
<h2>Audio pipeline</h2>
<p>
The audio pipeline has three modes: Direct, Full without audio filters, and Full with audio filters. Enabling audio filters
replaces other types of audio processing in the pipeline, thus the parallel path.
</p>
<blockquote>
<table class="pipeline">
<tr>
<th>Direct</th>
<th colspan="2">Full</th>
</tr>
<tr>
<td>Sequencing</td>
</tr>
<tr>
<td>Read audio</td>
</tr>
<tr>
<td rowspan="5"></td>
<td>Decompress audio</td>
</tr>
<tr>
<td>Format conversion</td>
<td rowspan="3">Filter graph</td>
</tr>
<tr>
<td>Resampling</td>
</tr>
<tr>
<td>Volume adjustment</td>
</tr>
<tr>
<td>Compression</td>
</tr>
<tr>
<td>Write audio</td>
</tr>
</table>
</blockquote>
<dl>
<dt>Sequencing</dt>
<dd>
Any audio edits take place here. These are basically the same in time as the video edits.
</dd>
<dt>Read audio</dt>
<dd>
Source audio is read from disk.
</dd>
<dt>Decompress audio</dt>
<dd>
Audio is decompressed using an audio codec, if necessary, producing uncompressed PCM audio. This is usually in
16-bit mono or 16-bit stereo format.
</dd>
<dt>Format conversion</dt>
<dd>
Precision and channel changes requested under <a href="d-audioconversion.html">audio conversion</a> now take
place, including switching between 8-bit and 16-bit samples, as
well as mixing down to mono or cloning channels to produce stereo.
</dd>
<dt>Resampling</dt>
<dd>
<p>
Changes in sampling rate requested in the <a href="d-audioconversion.html">audio conversion dialog</a> now take
place. If high quality mode is off, point sampling is used, otherwise linear interpolation is used.
</p>
<p>
If higher quality resampling is required, the resample audio filter should be used instead, which uses a multi-tap
windowed sinc filter.
</p>
</dd>
<dt>Volume adjustment</dt>
<dd>
<p>
If volume adjustment is enabled, the audio is now attenuated or amplified using a linear multiplication with
clamping.
</p>
</dd>
<dt>Compression</dt>
<dd>
<p>
The audio is now recompressed using the selected output audio codec. If no audio codec is selected,
the audio is simply written out using its current format.
</p>
</dd>
<dt>Write audio</dt>
<dd>
<p>
The finished audio is written to disk.
</p>
</dd>
</dl>
</lina:create>
<lina:create file="p-direct.html" title="Processing: Direct mode">
<p>
VirtualDub allows audio and video streams to be processed in <em>direct mode</em>. In this mode, data is simply
copied from input and output. This has the advantage of much faster rendering and no quality loss, while still
allowing a limited amount of editing.
</p>
<p>
Because of the way that audio and video compression works, there are some limitations imposed on the types and
locations of edits that can be done in direct mode. However, because audio and video modes are independent, it
is possible to have only one pipeline run in direct mode, and not incur the limitations that would be imposed
by the other.
</p>
<h2>Limitations on editing compressed video streams</h2>
<p>
Video compression imposes severe restrictions on where edits can occur in the video stream in direct mode.
Most compression occurs by removing redundant data between adjacent frames, which results in a <em>delta frame</em>
that is dependant on the previous frame to be decoded properly. The result is that the previous frame can't
be removed without making that delta frame undecodable. Frames which aren't dependant on the previous frame
are known as <em>key frames</em> and serve as anchor points in the stream for seeking and editing purposes.
</p>
<p>
The rule that must be heeded when editing a direct mode stream in VirtualDub is that <em>a portion of video to
be removed must end on a keyframe</em>.
</p>
<p>
Key frames are denoted by <tt>[K]</tt> next to the timestamp below the seek bar in VirtualDub; delta frames
are denoted by <tt>[ ]</tt> instead. Because selections in VirtualDub are <em>endpoint exclusive</em> —
meaning that the frame you end the selection on is not included in the selection — you want to <em>end the
selection on a key frame</em>.
</p>
<style>
table.timeline {
margin-left: 32px;
}
table.timeline th {
background: #8ae;
}
table.timeline td {
background: #aea;
padding-right: 16px
}
table.timeline td.cut {
background: #a88;
}
table.timeline td.broken {
background: #f00;
}
</style>
<p>
As an example, assume that you have a set of frames like this:
</p>
<table class="timeline"><tr>
<td>K</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>K</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>K</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr></table>
<p>
This cut is <i>kosher</i>:
</p>
<table class="timeline"><tr>
<td>K</td>
<td> </td>
<td> </td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut">K</td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut"> </td>
<td>K</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr></table>
<p>
This cut, however, is not, because it leaves a delta frame that is missing its predecessor:
</p>
<table class="timeline"><tr>
<td>K</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td class="cut">K</td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut">K</td>
<td class="cut"> </td>
<td class="broken"> </td>
<td> </td>
<td> </td>
</tr></table>
<p>
When such a cut is made, VirtualDub automatically adjusts the cut ranges until the restrictions of delta frame
compression are satisfied. Thus, the above cut would actually give the following:
</p>
<table class="timeline"><tr>
<td>K</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td class="cut">K</td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut"> </td>
<td class="cut"> </td>
<td>K</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr></table>
<p>
The rules for such automatic corrections:
</p>
<ul>
<li>VirtualDub will not let you write a video stream with dangling delta frames.</li>
<li>Frames are always added back in, but never removed, duplicated or reordered.</li>
</ul>
<p>
Thus, if you make a mistake, you can always load in the edited file and <em>re-edit</em> in direct mode, making a larger cut that satisfies
the rules.
</p>
<p>
The same restrictions apply to masking frames as to deleting frames; if an unmasked delta frame exists
after a masked frame, the masked frame will be converted to unmasked before the operation begins.
</p>
<p>
A <em>null frame</em> or <em>drop frame</em>, which is a zero-byte frame that simply duplicates the previous frame,
has special handling in VirtualDub's pipeline. These are denoted by <tt>[D]</tt> next to the timestamp indicator and
are occasionally produced during video capture.
Such frames are dependant upon the previous frame, but can still be removed without affecting decoding. Note that
these frames occupy time in the stream, however, and so deleting them will remove the corresponding audio segment
as well.
</p>
<p>
It is sometimes possible to bypass the restrictions on cut positions by using <a href="p-smartrendering.html">smart rendering</a>.
</p>
<h2>Video frame decimation/conversion in direct mode</h2>
<p>
The frame rate decimation and conversion modes resample a video stream by inserting or removing frames. This essentially
involves micro-editing of the stream at the frame level and suffers from similar limitations with compressed streams.
Here are the frame rate limitations when using direct mode:
</p>
<ul>
<li>
<em>Frame rate adjustment</em> simply tweaks the frame rate of the video stream and can be used without limitation.
</li>
<li>
<em>Conversion to a higher rate</em> works by inserting zero-byte null frames into the output stream, and can also
be used without limitation. (This means you can convert a 30fps stream to 120fps with no loss and with almost no
size increase.)
</li>
<li>
<em>Conversion to a lower rate</em> has to delete frames, but suffers from the limitation on dependant frame removal.
If used on a compressed stream, the option is only able to remove frames immediately before a key frame, which means
that sequences of delta frames are longer than a few frames, the video will stutter and audio sync will be affected.
Conversion to a lower rate is thus only usable with a stream that has few or no delta frames.
</li>
<li>
<em>Decimation</em> is equivalent to conversion to a 1/N frame rate and has the same issues.
</li>
</ul>
<p>
As with edits, null frames also receive special treatment here, so if a video has been upsampled from 30fps to 120fps
by inserting null frames, conversion can be used to discard the null frames and drop the stream back to 30fps.
</p>
<h2>Video streams that are direct-mode friendly</h2>
<p>
A video stream using a format that only uses key frames imposes no limitations on the location
of cuts in direct mode. Such formats include:
</p>
<ul>
<li>Any uncompresed RGB or paletted format</li>
<li>Any uncompressed YCbCr format (UYVY, YUY2, YV12, I420, etc.)</li>
<li>Video compression that only uses key frames, such as Huffyuv, Motion JPEG, or DV.</li>
</ul>
<p>
These formats are thus very friendly to direct-mode editing and are good choices for capture or intermediate
video files.
</p>
<h2>Limitations on direct-mode imposed by source format</h2>
<p>
MPEG-1 video streams cannot be copied in direct mode, because MPEG-1 video compression is incompatible with the
AVI file format. Also, MPEG-1 audio streams are always decompressed to raw PCM regardless of the audio mode setting.
</p>
<p>
DV files that use interleaved storage (type-1 DV AVI) may have their audio streams slightly modified when
processing the audio stream in direct mode, because VirtualDub has to resample the audio stream in some cases
to force a consistent audio sample rate. This is not a problem for AVIs that have the DV data split into
traditional audio and video streams (type-2).
</p>
<h2>Limitations on editing imposed by audio compression</h2>
<p>
Audio compression works by processing blocks of audio as individual units. In direct mode, VirtualDub copies these
blocks as atomic units, so the length of time corresponding to the block sets the minimum granularity for edits, and
thus the accuracy of edits that can be performed.<a href="#blockalign" class="footnotelink">[1]</a>
</p>
<p>
For some formats that simply translate samples 1:1, such as A-law and μ-law, the block size is one sample
and no restrictions are necessary. Other formats, such as ADPCM, can have a block size as large as 2048 samples
(0.18s at 11KHz). The <a href="d-audiocompression.html">audio compression</a> dialog indicates the block size for
each selectable format.
</p>
<p>
VirtualDub does <em>not</em> attempt to adjust edits to match audio granularity because the
audio block size rarely corresponds to an integral number of video frames in time, which would require fractional
edits. The difference between the ideal cut point and the cut point imposed by audio compression appears as sync
error and thus editing a compressed audio stream should be avoided if possible.
</p>
<p>
Some compressed formats, particularly MPEG audio layer III, have additional decoding restrictions that are not
described adequately in the audio format structure, such as dependencies on previous frames, or even specify a
block size that is blatantly false (namely, one byte). Because VirtualDub is not able to detect or correct for
such limitations, editing streams in such formats can result in audible decoding errors due to block fragments
at the cut point and is not recommended.
</p>
<p class="footnote" id="blockalign">
[1] The size of the block is set, in bytes, by the <tt>nBlockAlign</tt> field in the <tt>WAVEFORMATEX</tt> structure that describes the audio format.
Analog video is delivered using a mechanism known as <em>interlacing</em> to reduce flicker. Instead
of sending entire frames at 29.97 frames per second (25 for PAL/SECAM), the video is sent in halves called
<em>fields</em>, at 59.94 fields per second (50 for PAL/SECAM). These fields are <i>interlaced</i>
together such that a frame is composed of alternating lines from each field; the even lines make up
the <em>even field</em> and the odd lines make up the <em>odd field</em>. The result is high resolution
in static scenes and smoother motion in fast-moving scenes, with less flicker and without requiring
more bandwidth.
</p>
<p>
The catch with interlacing is that you can't have both higher resolution and smoother motion at the same
time, so artifacts appear whenever you try to extract both. The process of removing the interlacing and displaying the result non-interlaced is known as <em>deinterlacing</em>.
Displaying each field by itself gives smoother motion at the cost of resolution and is known as <em>bob deinterlacing</em>.
Pairing fields up and displaying them together as frames gives higher resolution in exchange for smeared
motion and combing artifacts and is called <em>weave deinterlacing</em>. Both produce frames at field rate
(59.94 or 50 fps). Trying to switch between the two
on a per-frame or even per-area basis depending on the amount of local motion is <em>adaptive deinterlacing</em>
and can produce an even higher quality image.
</p>
<p>
Most video capture devices do not attempt to deinterlace and simply pair fields together, which is similar
to weave deinterlacing except that it gives half the field rate (29.97 or 25). If the video was produced originally
from full frames at that rate, this has a 50/50 chance of producing whole frames instead of a combed mess.
There is no requirement that this be the case, though, and since the alternating fields are evenly staggered in
time they usually aren't. In that case there is no "correct" way to deinterlace the video, and different deinterlacing
techniques must be tried to produce the best quality non-interlaced video.
</p>
<p>
Material derived from 24 fps film is a special case in that the video is sourced from whole frames and split into
fields in a specific pattern; this is called <em>telecine</em>. In NTSC, this is done by slowing the video down very
slightly and combining fields in a 3:2 pattern; VirtualDub's inverse telecine feature, accessible in the <a href="d-videoframerate.html">video frame rate control dialog</a>,
can sometimes undo this pattern. In the case of PAL, the video is usually just sped up by 4% from 24 fps to 25 fps,
so the most that is usually required is a single-field delay to pair up the fields correctly.
